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Description 

[0001] This invention relates to video lottery qames and other video games of chance, and in particular, to a video 
gaming system providing games including a fixed pool of game plays and a predetermined number of winning plays 
5 within each pool. 

[0002] Lottery games where a player purchases a printed ticket and gambles on winning a prize or sum of money 
are known in the art. Lottery games of this type, however, generally require little or no skill on the part of the player to 
play the game. At most, some minimal physical act may be required of the player to reveal a preordained outcome 
included on the ticket. The outcome of the ticket has likely been detemnined in advance of the purchase, usually at the 
10 time the tickets are printed. In these games, a player can determine immediately whether the ticket was a winning 
ticket by simply examining the face of the ticket. 

[0003] Other lottery-type games that require additional, non-skilled acts on the part of the player are also known. 
These games may involve the scratching of a removable surface deposited on the face of the ticket in order to reveal 
whether the ticket constitutes a winning hand. The infomnation printed on the ticket will usually also indicate the amount 

15 of any prize won. In paper pull-tab versions of this type of lottery game, the player may peal back or tear off a paper 
covering to determine if the ticket was a winner. Even this version of the lottery ticket, however, lacks a sense of 
competition between other players or any feeling that a player can affect the outcome of the game. 
[0004] The recent proliferation of the video game has provided greater reach or marketability for such lottery or 
gambling devices. Video games of chance, such as video poker or video black jack, are examples of such video 

20 gambling machines. These video games are very accessible and can be installed in bingo pariors or gambling halls 
so that many players can play at one time. 

[0005] Even where these video lottery games or gambling devices have succeeded in attracting more players, they 
also have lacked an element of competition whereby a player can compete not simply against a machine, but against 
other players as well. Such competition would provide an element of thrill to tne known lottery game, or even require 
25 a degree of skill from a player. In the prior paper lottery systems or video gambling machines, the player essentially 
competes against the machine and has no indication that other players are also competing to win the same or different 
prizes. 

[0006] What is lacking, therefore, is a lottery game that would overcome the above disadvantages of the previous 
lottery systems and would provide the advantages of the now popular video games. These advantages include greater 
30 access to more players, ease of operation and administration, and minimal overhead in the fomn of human adminis- 
trators. Such a video lottery system would also provide a game where players could directly compete against each 
other and thus have an impact on their chances of winning. 

[0007] One video lottery game is described in U.S. Patent No. 4,652,998. but lacks this element of competition 
between players. According to the patent, a pool of tickets is produced and divided into mini-pools among multiple 
35 terminals operable by various players. Each mini-pool includes a fixed ratio of winning tickets that are allocated from 
the greater pool. However, each player only purchases plays from the respective mini-pool allocated to his temninal 
and gambles on the random nature of prize distribution within that pool. Simultaneous competition against other players 
is not provided. 

[0008] A further system is shown in US-A-5042809. In this document, players are able to select and purchase game 
40 plays from a fixed pool and the system indicates if the game play purchased constitutes a winning play This disclosure 
concerns a single player game and does not provide competition either. 

[0009] In view of the above, the present invention provides a gaming system as set out in appended claim 1 . 
[0010] The preferred embodiments described below combine the advantages of the prior paper lottery systems with 
the ease and popularity of the video game. As in the paper lottery systems, each player purchases a video lottery play 
45 from a fixed pool of such plays. As in the paper lottery systems, each game play has a predetemained chance of winning. 
The video lottery system, however, has the advantage, in the prefen-ed embodiment, of continuously updating each 
player on the chances of purchasing one of the remaining winning plays In the pool. Use of computers and video 
terminals also affords on-line competition among the many players that can simultaneously play the lottery games at 
the same or remote locations. 

50 [0011] In the preferred embodiment, many players are capable of simultaneously competing against each other for 
a predetennined number of winning plays provide in a fixed pool of lottery game plays. Such competition urges players 
to race in order to purchase the remaining winning plays within each fixed pool of plays before none remain. An element 
of strategy and skill is thus introduced since a player may decide to wait for the odds of purchasing a winning play to 
increase by allowing other competitors to purchase some of the remaining non-winning plays, thereby increasing the 

55 odds of purchasing a winning play at a later time. Displaying on a continuous basis the number of remaining plays and 
the number of winning plays already redeemed allows each player to assess the risk in purchasing another play or 
whether to cease playing until a new game is initiated. 

[0012] These and other features and advantages will be apparent upon consideration of the following detailed de- 
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scription of the presently preferred embodiments of the invention, taken in conjunction with the appended drawings. 

FIG. 1 is a block diagram of one preferred gaming system made according to the invention; 
FIG* 2 Is a block diagram of one prefen-ed central game processor employed in the gaming system shown in FIG. 1 ; 
5 FIG 3 is a graphical depiction of the software architecture employed in the central game processor shown in FIG. 2; 

FIG. 4 is a state diagram for an incoming call state machine employed in the central game processor shown in 

FIG. 3; ^ . .r.r- . 

FIG. 5 is a block diagram of one preferred master processing unit employed In the gaming system shown in Fit., i ; 
FIG. 6 is a graphical depiction of the software architecture employed in one preferred embodiment of a master 

w processing unit shown In FIG. 5; 

FIG. 7 is a flow chart of a preferred background processing routine shown in FIG. 6; 

FIG. 8 is a block diagram of one preferred slave temninal employed in the gaming system shown in FIG. 1 ; 

FIG 9 is one presently preferred flow chart of the functions performed on the slave terminal shown in FIG. 8. where 

FIG 9A illustrates main execution flow on the slave terminal. FIG. 9B illustrates flow of the play selection subroutine. 

15 FIG 9C illustrates flow of the command response subroutine, FIG. 9D illustrates flow of the wager selection sub- 

routine FIG. 9E illustrates flow of the cash out subroutine, FIG. 9F illustrates flow of the transaction cancel sub- 
routine! FIG. 9G illustrates flow of the open single tab or open all tabs subroutine. FIG. 9H illustrates flow of the 
select ticket subroutine and FIG. 91 illustrates the wager deposit subroutine; 

FIGS 10-13 are preferred circuit diagrams of a general purpose input/output interface adapter employed in the 
20 slave terminal shown In FIG, 8, where FIGS. 10A & 10B together show signal decoding circuitry, FIG, 11 shows 

the memory logic, FIG. 12 shows sound generation circuitry and FIGS. 13A & 13B together illustrate the input/ 
output interface; 

FIG. 14 is a preferred illustration of one display produced on a video monitor employed in the slave terminal shown 

'f^ FIG. 8; , . . „ 

25 FIG. 1 5 is subsequent display produced on the video monitor of the slave terminal showing a preferred video lottery 

ticket' 

FIG. 1 6 is further successive display of the video lottery ticket shown in FIG. 1 5 prior to being opened; 
FIG. 1 7 illustrates the video lottery ticket shown in FIG. 1 6 after being opened; 
FIG. 1 B is a graphic depiction of the master/slave communication files; and 
30 FIG. 1 9 is a depiction of the globally accessible data structures employed.in the gaming system shown in FIG. 1 . 

[0013] Reference is now made to the drawings where like elements are identified by like numerals throughout. FIG. 
1 shows a gaming system made according to a prefen-ed embodiment of the invention, generally designated at 10. 
The gaming system 1 0 includes a central game processor 1 2, which controls and administers operation of the gaming 
35 system 1 0. Preferably, remotely located from the central game processor 1 2 are multiple master processing units 1 4. 
In one embodiment of the invention, the master processing units 14 are connected to the central game processor 12 
employing a telephone link. In this embodiment, up to sixteen telephone lines 1 8 are used to connect between modems 
22 provided with each master processing unit 1 4 and the multiple-line modems 24 provided in the central game proc- 
essor 12. . A J. * *U 

40 [0014] A plurality of slave terminals 16 are in tum connected to each master processing unit 14, According to the 
prefen-ed embodiment, up to twenty slave terminals 16 can be configured to each master processing unit 14. In this 
embodiment, the slave terminals 1 6 are Interconnected through a local area network (LAN) 20. The local area network 
20 also couples the slave temriinals 16 to their respective master processing unit 14. 

[001 5) Although a preferred system configuration has been described, it will be appreciated by those skilled in the 
45 art that a number of different system configurations are possible without departing from the spirit and scope of the 
invention As will be appreciated, the combination of components provided in the gaming system 10 compnses an 
integrated computer system capable of operating an electronic lottery/ gambling system or other similar games. Each 
component of the gaming system 10 provides a specific function necessary to operation of the gaming system 10 as 
a whole. However, these functions can be further distributed or combined among other computer architectures. 
50 [001 6] As will be described more fully below, each element of the system 1 0 (the central game processor 1 2, the 
master processing units 14. and the slave tennlnals 16) also executes one or more computer programs in order to 
perfonn their respective tasks. The preferred computer programs addressed below may also take on different fomns 
without departing from the spirit and scope of the Inventior. 

[0017] The purpose of the central game processor 12 is two-fold: (1) the central game processor 12 electronically 
55 generates each fixed pool of game plays provided on the gaming system 10. and (2) serves as an interface to each 
master processing unit 1 4. The central game processor 1 2 thus acts as a repository for. and coordinates the production 
of graphic data and game play infomiation. The central game processor 12 supplies, or downloads, the fixed pools of 
game plays to each master processing unit 14. and also perfomns periodic audit and security checks of the master 
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processing units 14. 

[0018] Each master processing unit 14 also contributes a unique function to the gaming system 10. The purpose of 
the master processing units 14 is primarily to manage the game plays being requested at the slave terminals 16. The 
master processing units 14 administer the games as they are being played at the slave temninals 1 6. In the adminis- 

5 tration of the games, the master processing units 1 4 provide audit information about each of the stave terminals 1 6 to 
the central game processor 12. The master processing units 14 also handle the summation and temnination of each 
player's game play by calculating each player's winnings and providing the player with a receipt. 
[0019] The slave terminals 16 provide the player interface to the gaming system 10. The purpose of each slave 
terminal 16, therefore, is to handle and process game play requests from each player. Each slave temninal 16 keeps 

10 track of each player's winnings and serves as a repository for each player's wagers. As part of the player interface, 
each slave tenninal 16 detects if the game play cunrently requested by a player constitutes a winning play, and if so. 
displays to the player the amount won. 

[0020] One objective of the presently preferred gaming system 1 0 is to simulate, through a video game embodiment, 
the action and play of a paper pull-tab lottery game. The gaming system 10, however, is also capable of supplying a 
15 variety of other games including more sophisticated games. Examples of such games include slot machines, keno, 
bingo, and roulette. 

[0021] According to the preferred embodiment of the invention, several players are capable of participating and 
simultaneously playing the games provided by the gaming system 10, Each player participates by purchasing plays 
through a respective slave tenninal 1 6. Each master processing unit 14 maintains a fixed pool of game plays supplied 

20 from the central game processor 12 to be transmitted to the slave terminals 16. Thus, as in the paper pull-tab lottery 
games, each player has access to and can purchase plays from the entire fixed pool of game plays stored at each 
master' processing unit 14. Through the use of a player-controlled selection device (e.g., pushbuttons or the like) a 
player can request and purchase game plays and gamble on purchasing a winning play. Each player's activities, there- 
fore, bear a direct result on the outcome of purchasing subsequent plays from the fixed pool of game plays stored at 

25 the master processing units 14. 

[0022] In the preferred embodiment, it is important that each game retain the play and feel of the paper puli-tab lottery 
games. Thus, each player is continuously alerted regarding how many plays remain in each fixed pool. The number 
of plays remaining need not be displayed as a numeric count per se, but may appear visually as a graphic represen- 
tation. In a typical game to be played on the gaming system, between 1200 and 4800 plays are included in each fixed 

30 pool of game plays. In an alternate embodiment, however, the gaming system 1 0 has the ability to handle "lotto" type 
games including a million plays or more. 

[0023] In the preferred embodiment, each master processing unit 14 can dispense up to twelve or more games 
simultaneously, and each slave tenminal 1 6 is continuously infomned as to the amount of plays remaining in each fixed 
pool of plays. As an added feature, if many slave terminals 16 are located in a single gambling hall or casino, each 
35 slave terminal 16 will display to the player the various events happening within the hall. Announcements regarding 
closing of the hall, or that another player has won enhances the feeling that each player is competing against a group 
of players and not just against the machine itself. 

[0024] The video pull-tab lottery games administered by the gaming system 10 preferably have the following char- 
acteristics. A video representation of a pull-tab ticket is provided on the slave terminals 1 6 showing which combinations 

40 of symbols comprise a winning play. This video "tickef comprises one of the fixed pool of plays provided by the central 
game processor 1 2 for eacn pull-tab game. The gaming system 1 0 also displays the video ticket both before and after 
it has been opened. Such display illustrates the appropriate graphic symbols that indicate either a winning or losing 
play. A mechanism that allows each player to manage his betting while the game is being played is also provided. 
Features of this mechanism include facilities for crediting, debiting, depositing and withdrawing wagers as required by 

45 each player during play of the game. 

[0025] As mentioned, software is employed throughout the gaming system 1 0 in order to provide the fixed pools of 
game plays and to coordinate the activities taking place In the gaming system 10. The central game processor 12 
includes a program for generating the fixed pools of game plays for each game supplied in the gaming system 10. As 
provided in the paper pull-tab lottery games, each fixed pool of game plays includes a predetemnined number of winning 

50 plays. This predetermined number of winning plays is fixed at the generation of each pool of game plays. As a result, 
in a fixed pool of "x" game plays and "y" winning plays, there are x - y = "z" game plays that do not constitute a winning 
hand. Software provided on the slave terminals 1 6 continuously indicates to each player the number of winning plays 
already purchased from each fixed pool and thus provides an indication of the chances of purchasing a subsequent 
winning play. 

55 [0026] Software is also provided to configure and operate the components of the gaming system 1 0 to perform their 
intended functions. The specific functions perfonned by each of the components of the gaming system 10 is described 
in more detail below. 
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I. Central Game Processor 12 

[0027] Referring to FIG. 2. the central game processor 1 2 comprises a central computer 30. In the prefen-ed embod- 
iment, the central computer 30 can be an IBM Personal Computer-AT (or the equivalent), including an 80386 (or 80486) 
5 microprocessor 32 manufactured by Intel Corp., Santa Clara. California, which preferably operates at a thirty-three 
megahertz clock speed. Further provided on the central computer 30 is a hard disk drive 34 and random access memory 
(RAM) 36. In order to provide ample storage space for the software running on the central game processor 1 2, prefen-ed 
sizes for these memory devices range from 80- to 1 00-megabytes for the hard disk- drive 34 and four megabytes for 
the RAM 36. 

10 [0028] To facilitate communication with the master processing units 14, the central computer 30 also includes a 
plurality of modems 24, or a multi-channel communication card (not shown). To achieve the necessary data throughput, 
the modem 24 preferably operates at 2400-baud or higher. To complete the architecture of the central game processor 
12, the central computer 30 also includes a video monitor 40 and an associated video graphics adapter (VGA) card 
42, a keyboard 44, and a printer 46. 

15 [0029] The central game processor 1 2 operates as the central or coordinating computer for the overall gaming system 
10. One function of the central game processor 1 2 is to issue new fixed pools of game plays and new games to each 
master processing unit 14 as they are needed. The central game processor 12 thus keeps an adequate inventory of 
the games currently being offered, and ensures that the system itself is operating properly. A prime function of the 
central game processor 12, therefore, is to communicate with each master processing unit 14 and to supply each 

20 master processing unit 1 4 with more pools or more games. 

[0030] In the preferred embodiment of the invention, new pools of game plays are entered by operators at the central 
game processor 1 2. Operators simply key in data from preexisting paper pull-tab lottery tickets into the central computer 
30. As will be described in more detail below, software running on the central computer 30 converts the raw symbol 
and deal data entered by the operators into several files to be used in the gaming system 1 0. For example, one of such 

25 software programs examines the data entered for each paper ticket and searches for winning symbol combinations. 
Winning combinations are identified by the central computer 30, which stores temporarily the amount won for that 
combination. When all combinations and directions (horizontally, vertically and diagonally) have been scanned and 
scored, the final amou nt won is appended to the ticket data (described in detail below) and stored in the central computer 
30. As is the case with most tickets, if no winning combinations are detected, the amount won will be zero and stored 

30 as such with the ticket data. When all tickets have been entered and scanned by the central computer 30, the pool of 
tickets is stored for subsequent transfer upon request from the master processing units 1 4. 

[0031] In order to perform its tasks, the central game processor 12 should preferably receive and log update requests 
•from each master processing unit 1 4. Conversely, the central game processor 1 2 is able to poll each master processing 
unit 1 4 to request status about the specific local area network 20 configuration and the individual status of each slave 

35 terminal 1 6 connected thereto. The central game processor 1 2 thus becomes both the logical and physical link between 
all of the master processing units 14. A detailed description of the communication protocol between the master game 
processors 14 and the respective slave terminals 16 is provided below in connection with FIG. 18. 
[0032] In the preferred embodiment of the invention, the central game processor 1 2 comprises a personal computer 
or minicomputer. The functions described above, as well as additional functions, are thus contained in software pro- 

40 grams that execute on the central game processor 1 2. For example, such software enables the central game processor 
12 to transmit codes in order to communicate with each master processing unit 14. These codes communicate instruc- 
tions to the master processing units 1 4 to cause information stored in the master processing unit 14 to be transmitted 
to the central game processor 12. The software also enables the transmission of new game designs from the central 
game processor 12 to each master processing unit 14. Further, software is provided to poll each master processing 

45 unit 14 in order to detemnlne gaming patterns and trends. 

[0033] A graphical depiction of the software architecture for the central game processor 1 2 is shown in FIG. 3. Both 
foreground 50 and background 52 tasks are performed by the software operating on the central computer 30. Fore- 
ground tasks 50 handle a menu-driven operator interface, which receives input from the system administrator sitting 
at the video monitor 40 and keyboard 44. Executing in the background Is a routine for handling incoming calls from 

50 the master processing units 14. Each call comes Into the central computer 30 over a series of telephone lines 18 and 
is received by the plurality of modems 24 included in the central game processor 12. After the incoming call is processed 
by the communications software 54, the central game processor 1 2 must determine how to respond to the call. Provided 
in FIG. 4 is a state machine included in the central computer 30 that handles the incoming calls. 

55 II. Master Processing Unit 14 

[0034] A preferred embodiment of one master processing unit 14 is shown in FIG. 5. In the preferred embodiment 
shown in FIG . 5, each master processing unit 1 4 includes a master computer 70. The master computer 70 is preferably 
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an IBM Personal Computer-AT type computer, including an 80386 microprocessor 72 manufactured by Intel Corp., 
Santa Clara. California, and operated at a clock speed of thirty-three megahertz. The master computer 70 also includes 
a hard disk memory 74 and on-board RAf^ 76. To satisfy the software needs of the master processing units 14, the 
hard disk memory 74 should be at least 80-megabytes and the on-board RAM 76 should include between two and four 
megabytes of addressable space. 

[0035] Further provided on the master computer 70 is a 2400- to 9600-baud modem 22 for communication with the 
central game processor 12. and a LAN interface 80 for communication with the plurality of slave terminals 1 6 coupled 
to the master processing units 14. The LAN interface 80 on the master processing unit 14 is thus similar to that provided 
in each slave terminal 16 (described below). A video monitor 82 and associated video graphics adapter card 84 are 
also included in the master computer 70, as is a keyboard 86. The master computer 70 may also include an optional 

printer 88. ... 
[0036] Each master processing unit 1 4 has two primary responsibilities: (1 ) to perform certain requests initiated from 
the centra! game processor 12. and (2) to maintain continuous communication with each slave tenninal 16. As part of 
its first task, each master processing unit 14 responds to requests initiated by the central game processor 12. In the 
preferred er^bodiment, each master processing unit 14 stores at least one fixed pool of game plays received from the 
central game processor 1 2. Each master processing unit 14 further includes passwords for four levels of access to the 
master processing units 14. These passwords are distributed to the various levels of master administrators operating 
each master processing unit 14. One password is preferably employed to start the game, and at least one other pass- 
word is required to change or display any network parameters. 

[0037] As part of its second responsibility, each master processing unit 14 is prepared to respond to requests from 
the slave terminals 16 configured on its local area network 20 (FIG. 1). A primary function of the master processing 
units 1 4 is to download game plays requested from the slave terminals 1 6 from the fixed pool of game plays stored in 
the master processing unit 14. Each master processing unit 14 can also request the status of each slave terminal 16, 
generate and send a validation code to any slave temninal 16. and broadcast messages to all slave terminals 16 
connected to its local area network 20. 

[0038] The master processing unit 1 4 also has the ability to view network activity in order to determine the status of 
a particular game being played at the various slave terminals 16. In a preferred embodiment, the master processing 
unit 1 4 displays to a master administrator (bingo hall or gambling operator) an inventory report of the games currently 
offered on the gaming system 10. The master processing unit 14 also displays the status of its network, i.e.. the status 
of each slave terminal 16 connected to the master processing unit 14. and provides an audit report regarding each 
particular slave terminal 16. The master processing unit 14 also displays the status of each pool, which includes an 
indication of the amount of plays remaining. A list is also provided of game options, which are selectable at each master 
processing unit 14 by the master administrator. 

[0039] As play on the gaming system 10 commences, the main duty of the master processing unit 14 is to poll the 
slave terminals 16, one-by-one, to provide their status. The collection of status infomnation is done such that each 
player will not notice a delay in response time from his or her slave temntral 16. The status of each slave terminal 16 
may be one of five states: (1) enabled, (2) disabled, (3) out of service. (4) not responding, and (5) operational. 
[0040] Each master processing unit 14 also includes facilities to shut down its local area network 20 In an orderly 
fashion, and then power down its branch of the gaming system 1 0. Thus, each master processing unit 1 4 of the gaming 
system 10 configures its local area network 20 on a case-by-case basis. 

[0041] A graphical depiction of the software architecture for the master processing units 14 is provided in FIG. 6. 
Each master processing unit 14 preferably perfonns internal diagnostics upon power-up. After the diagnostics are 
completed, a password or log-on code is required from the master administrator to start the games, as described above. 
After the proper log-on has been initiated, the display appearing at each master processing unit 1 4 continuously shows 
the status of each slave temiinal 16 connected to its local area network 20. 

[0042] As shown in FIG. 6. foreground 60 and background 62 processing is performed at the master processing 
units 14. In the foreground, a menu-driven user interface is provided to handle communication to and from the master 
administrator. Information received from the master administrator is communicated from an operator display 66 and 
handled by the foreground processing routines. 

[0043] Background processing 62 on the master processing unit 14 handles messages received from the slave 
terminals 16. Information from the slave terminals 16 is received by the master processing unit 14 over its local area 
network 20. Similarly, game plays from the fixed pool of game plays stored in a database 64 located on the master 
processing unit 14 are communicated over the local area network 20 to the slave tenninals 16. A flow chart of the 
background processing 62 perfomied on the master processing unit 14 appears in FIG. 7. 

[0044] As shown in FIG. 7, at steps 90, 91 , the background loop normally reads and displays the time of day until a 
command (ticket validation, audit, etc.) or response is received from a slave temninal 16. If a command or response 
has taken place, the master processing unit 14 must determine how to react. As shown at steps 92, 93. if a specific 
command is pending at the master processing unit 14. the command is sent to the requesting slave tenninal 1 6 over 
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the local area network 20. If not, the master processing unit 14 nnay poll the slave terminal for its status at step 94. 
[0045] After transmitting a command, the master processing unit 14 detennines at steps 97, '98 whether the slave 
temiinal 16 has responded appropriately. If so, the master processing unit 14 processes the response at step 95. After 
completion of these tasks, the background routine relinquishes control of the master processor at step 96. 
[0046] In order to access any of the remaining features provided at each master processing unit 14, a second or 
third password may be required as explained above. Examples of the remaining features provided by the master 
processing units 14 include selection of game options, record keeping and audit-oriented tasks. A detailed description 
of these functions is provided in more detail below. 

III. Slave Temiinal 16 

[0047] FIG. 8 is a block diagram of one preferred embodiment of a slave tenninal 16. At the heart of each slave 
terminal 16 is a slave computer 100. The slave computer 100 can be in one preferred embodiment an IBM Personal 
Computer, or a minicomputer or personal computer of similar function. The slave computer 1 00 thus preferably includes 
a microprocessor 106 and a video graphics adaptor 108, which connects to a color monitor 110. In the prefen-ed 
embodiment of the invention, the slave computer microprocessor 106 is an 80286 (or 80386) microprocessor manu- 
factured by Intel Corp., Santa Clara, California, which preferably operates at a twenty megahertz clock speed. 
[0048] Included in the slave computer 1 00 is a LAN interface 1 02 for communication to the master processing unit 
14. The LAN interface 102 couples to a LAN connector 104 provided on the slave terminal 16, which ties each slave 
tenninal 16 to its respective local area network 20 (FIG. 1). The LAN connector 104 preferably comprises a BNC T- 
type connector for configuration to the local area network 20. In the slave computer 100, the LAN interface 1 02 uses 
inten-upts "IRQ3" or "IRQ15" to communicate with the microprocessor 1 06. and preferably is ROM-base selectable. A 
programmable read only memory (PROM) used to boot start the slave terminal 1 6 is also included in the LAN interface 
102. 

[0049] The color monitor 1 1 0 included in each slave tenninal 1 6 is an essential element to the player interface of the 
gaming system 1 0. In the preferred embodiment, each color monitor 1 1 0 displays the video version of the paper pull- 
tab lottery ticket that comprises a preferred game play in the gaming system 10. Preferably, the color monitor 110 
produces a 640 x 480 x 256 non-interiaced display. The smaller the dot pitch of the color monitor 1 1 0, the more accurate 
the display; however, extremely high graphics resolution is not a critical item of the slave temninal 1 6. The video graphics 
adaptor 108 consequently provides the same 640 x 480 x 256 non-interiaced display, and is preferably capable of 
displaying up to 256 colors simultaneously. The video graphics adaptor 1 08 also includes approximately one megabyte 
of on-board memory (not shown) to achieve the displays contemplated for use in the prefen-ed gaming system 1 0. The. 
memory provides storage for video graphics software drivers and other video graphics processing elements. 
[0050] The Bios type employed in the slave terminals 16 may be any of the commercially available Bios types, so 
long as a keyboard (not shown) provided on the slave temninal 1 6 can be disabled through software. The slave computer 
1 00 should also preferably include at least 51 2-kilobytes of random access memory to accomplish its many tasks in a 
reasonable time. 

[0051] As shown in FIG. 8, a general purpose input/output (t/O) interface adapter 116 is also coupled to the micro- 
processor 106. The general purpose I/O interface adapter 116 preferably resides at memory address D800H. In the 
preferred embodiment, the general purpose I/O interface adapter 1 1 6 comprises a custom printed circuit board, which 
is described in greater detail below in connection with FIGS. 10-13. The general purpose I/O interface adapter 116 
connects to a speaker 120 located on the exterior of the slave temninal cabinet 115. The speaker 120 projects the 
various sounds used during the play of the games on the gaming system 10. These sounds are stored and generated 
by a sound generator chip located in the general purpose I/O interface adapter 116 (described below). Connected to 
the general purpose I/O interface adaptor 116 is a battery backed RAM 118. A door 122 is also provided in the slave 
computer cabinet 11 5 to allow operator or service access to the general purpose I/O interface adaptor 116. 
[0052] Configured to the general purpose I/O interface adaptor 116 are the necessary electro-mechanical devices 
required to implement the gaming system 10 of the invention. In the preferred embodiment, these elements include a 
wager accepter, preferably in the fonn of a bill accepter 124 and a coin acceptor 126, a plurality of player-controlled 
selection devices in the fomi of pushbuttons 128. and indicator lights 130, The front switch panel of the slave temninal 
16 may Include as many as ten such player controlled pushbuttons 128. The bill acceptor 124 located on the slave 
terminal 16 is preferably capable of accepting denominations from $1 to $20. Also provided in the slave tenninal 16. 
are five 16-bit expansion slots (not shown) for future expansion or customization, a hopper 132 to retain wagers and 
at least four digital meters 134 to display scores, etc. 

[0053] Each slave terminal 1 6 also preferably provides a validation ticket to the players after the player is through 
playing. The slave computer 100 also includes a printer 1 12 to provide a hard copy printout of its status. The interface 
between the microprocessor 106 and the printer 112 is accomplished through a printer interface card 114 as shown in 
FIG. 8. 
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[0054] Referring to FIGS. 9A-9I, a flow chart of the functions performed by the slave terminal 16 is provided. The 
functions identified in FIGS. 9A-9I are preferably implemented through software residing at the slave terminals 16. At 
steps 21 0 21 2 of FIG 9A execution begins and all variables are initialized. At step 21 4 the program checks for a power 
failure and if power has failed, at step 21 6 corrective action is taken and flow proceeds at step 21 8 to pick up where 
execution left off (see FIG. 9B below). At step 224 the program detemiines if player credits are available from either 
wager deposits or a player^s winnings. If there are no credits available, then the particular slave temiinal 1 6 is not being 
used and the slave terminal 16 Is idle. While not in use, the slave terminal 16 executes a demonstration loop at steps 
220, 222 and displays an "attract" screen (discussed below). At step 222 the program checks for any communication 
sent from the master processing unit 14. .... 
[0055] If credits are available at step 224, the program proceeds with play of the game. At step 226, a "select value 
screen is displayed and at step 228 the program waits for player entry. While waiting, tne program again checks at 
step 230 for communications from the master processing unit 1 4. Player entry can come in the form of any of the player 
controlled pushbuttons 128 provided on the slave temiinal cabinet 115 (FIG. 8). A prefen-ed set of pushbuttons 128 is 
illustrated in FIG. 9A, which correspond to wager denomination pushbuttons 234. 236, 238 (Group 1) or play action 

buttons 242-250 (Group 2). . u *u 

[0056] Referring now to FIG. 9B. should a player depress the Play push-button, the program first detennines whether 
enough player credits are available at step 254. If not. the program branches back at step 256 to wait for correct player 
input. If enough credits are available to the player, at step 258 the program initiates a ticket request to the master 
processing unit 14 Upon receipt of the ticket data from the master processing unit 14, the player's credits are decre- 
mented to reflect the wager amount at step 260 and the data received from the master processing unit 14 is loaded 
into the RAM 118 on the slave terminal 16 (FIG. 8). At step 264, the program displays an unopened video ticket and 
waits for new player input at step 266. 

[0057] FIG. 9C illustrates the flow of communication between the slave terminals 1 6 and the master processing unit 
14 As mentioned above, the slave terminal periodically checks to detemiine if there is a command pending from the 
master processing unit (step 268). If not. program flow returns to the main slave routine at step 270. If a command is 
pending from the master processing unit 14. a response is required by the slave terminal 16. In the preferred embod- 
iment of the invention shown in FIG. 9C, a variety of slave terminal responses 272 are available for the various com- 
mands sent by the master processing units 14 (described below). 

[0058] Further player input provided at step 228 of FIG. 9A is illustrated in FIGS. 9D-9H. FIG. 9D illustrates program 
flow upon selection of one of the wager denomination (Group 1 ).pushbuttons 234. 236, 238. At step 274 the wagered 
amount is set, and at steps 276, 278 the program awaits selection of one of the play action (Group 2) pushbuttons 
242-250. Should the player select the Gash Out push-button . the program then detemiines if the player has any credits 
to redeem (step 278) . If not. at step 280 the program returns to wait for valid input. If credits are available to be redeemed . 
at step 282 the program requests a validation number from the master processing unit 14. Upon receiptof the validation 
number, at step 284 a validation ticket is printed and at step 286 the player's credits are cleared. The program then 
returns to the demonstration mode at step 288. 

[0059] Referring to FIG. 9F, the player may select the Cancel pushbutton. If so and if a ticket face is being displayed 
at step 290. the program branches to again display the "select value" screen at step 292. If not, at step 294 the program 
returns to the main program flow. 

[0060] Should the player select the Open Tab X or Open All pushbutton, program flow continues at step 246 shown 
in FIG 9G At step 296 the appropriate tab or tabs are opened and the "underlying" ticket symbols are displayed. The 
program then determines if all tabs are open at step 298. If not, at step 230 the program branches back for more player 
input (i.e.. open the next tab). If all tabs are open, the player credits are incremented at step 302 if a winning ticket was 
selected. If a winning ticket has been purchased, at step 304 a congratulatory display is also presented. The program 
then returns at step 306 to await new player input. 

[0061] Should the player depress the Select pushbutton, at step 308 of Fig. 9H the program displays the face of the 
next available ticket in the fixed pool of game plays. At step 31 0. the program waits for new player input. 
[0062] Referring to FIG. 91. a wager subroutine is illustrated. At step 31 2, an interrupt is generated to the microproc- 
essor 1 06 (FIG. 8) and at step 31 4 the player's credits are increased according to the wager amount deposited by the 
player into the slave terminal 16. At step 316, the program then returns to the main program flow of FIG. 9A 
[0063] Referring now to FIGS. 10-13, detailed schematic diagrams of the genera! purpose I/O interface adapter 116 
are provided. As seen in FIGS. 10-13, a plurality of programmable array logic devices (PAL's) 140 are employed 
throughout the general purpose I/O interface adapter 116. The PAL's 140 comprise much of the interconnect circuitry 
and help reduce the chip count on this printed circuit board. In one preferred embodiment of the invention, the PAL's 
140 are programmed using the TANGO-PLD (Version 1.11) PAL assembler. Copies of the programming equations for 
the PAL's 140 employed in the general purpose I/O interface adapter 116 are provided in the Appendix. 
[0064] In addition to the PAL's 140. a plurality of buffers/drivers 142 are provided throughout the circuitry shown in 
FIGS 10-13. These buffers/drivers 142 help boost, latch and clock signals as they propagate through the general 
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purpose I/O interface adapter 1 1 6. As shown in FIG. 11 , a RAM 1 44 is also provided in the general purpose I/O interface 
adapter 116 Jn preferred ennbodiment, the RAM 144 is 32 kilobytes in size. 

[0065] Referring to FIG. 12, a sound generator integrated circuit (IC) 146 is included in the general purpose I/O 
interface adapter 116. The sound generator 10 146 produces and stores the sounds projected from the speaker 120 

5 (FIG. 8) employed with the gaming system 10. As those skilled in the art will appreciate, such sounds can take on 
many different forms depending on the games being played on the gaming system 10 and personal tastes. 
[0066] Referring to FIG. 13B, a number of Darlington Drive current boosters 148 are also provided in the general 
purpose I/O interface adaptor 116. The Darlington current boosters 148 are used in the preferred embodiment to drive 
the indicator lights 130. the bill accepter 124, coin accepter 126 and the digital meters 134 appearing on the slave 

10 terminal 16 (see FIG. 8). 

[0067] As can be seen, in the preferred embodiment shown in FIGS. 10-13 many integrated circuits are employed 
to perform various functions in the general purpose I/O interlace adapter 116. To meet the prefen-ed response times 
for the gaming system 1 0, therefore, these integrated circuits should possess no more than an 80- or 1 00-nanosecond 
propagation delay in order to provide a zero-wait state environment for the gaming system 1 0. 

15 

IV. Gaming System 10 Operation 

[0068] In the gaming system 1 0, the slave terminal 1 6 operates as follows. Preferably, the slave temiinal 1 6 first runs 
a set of internal diagnostics each time it is turned on. (As shown in FIG. 8, each slave computer 100 is connected to 

20 its own power supply 136.) Since each master processing unit 14 preferably shows a graphic map of its slave network 
during operation of the gaming system 10, if a slave terminal 16 does not pass its internal diagnostics, the network 
map will show that slave temiinal 1 6 as "ENABLED" but "NOT RESPONDING". It is the master administrator's task to 
determine what to do to resolve the slave temninal 1 6 error, such as placing a call for service to a local distributor or 
service representative. When the slave terminal 16 passes its internal diagnostics, the master processing unit 14 will 

25 show the slave temiinal 16 as "ON-LINE". 

[0069] The slave terminal 1 6 next displays an introductory display on the color monitor 11 0 to attract attention and 
players. This attract screen includes demonstration graphics of game operation in a manner known in the art. A depiction 
of a front view of a slave terminal cabinet 115, including a display of the attract screen appearing on the color monitor 
110, is shown in FIG. 14. 

30 [0070] Preferably located at the top or bottom of the display is a field 1 60 used to broadcast messages received from 
the master processing units 14. As described more fully below, one of the tasks of the master processing units 14 is 
to broadcast to each slave temninal 16 messages regarding the game pool currently being played on that master 
processing unit 14. These messages are employed to convey infomnation regarding other players' betting to create an 
atmosphere of competition over the gaming system 1 0. An example of these messages include: "Another winning play 

35 has been purchased on machine 6111"; or "Congratulations to the player on machine 2, who just selected a $250 winning 
playlll". In a preferred embodiment, these messages are displayed on each slave terminal 1 6 regardless of whether it 
is sitting idle or is in the middle of a play. 

[0071] As shown in FIG. 14. a "CREDITS" field 162 is preferably located in the upper left hand comer of the display 
appearing on the color monitor 1 1 0. An indication of the number of tickets remaining in the pool currently being played 
40 is also provided in the upper right hand corner of the display. In the prefen-ed gaming system 10, each time a player 
deposits a wager in the appropriate slot on the slave terminal 16, the CREDITS field 162 is updated. Deposit of the 
wager also commences play on the gaming system 10. 

[0072] Referring to FIG. 15, after the placement of a wager the display changes to show the face of a video ticket 
164 (corresponding to the face of a paper pull-tab ticket) on the left hand side of the display screen 165. As play 

45 progresses, if the player next depresses the Play pushbutton 166 (FIG. 14), the slave temiinal 16 wilt electronically 
request a play from the pool of remaining plays stored at the master processing unit 14. In response, the master 
processing unit 14 will transmit to the slave temninal 16 a packet of ticket data representing the purchased play. Each 
play corresponds to a video pull-tab ticket in the preferred embodiment of the invention. The data received is stored 
on the slave terminal 16 to be interpreted after the player depresses the next appropriate pushbutton. 

50 [0073] In the preferred embodiment of the master processing unit 1 4 employing the 80286 microprocessor, the worst 
case response time for the slave temninal 1 6 to receive a play will be approximately 0.83 seconds. However, the average 
response time is likely to be 0.42 seconds depending on the number of players currently participating. When the play 
is received at the slave terminal 1 6, the CREDITS field 1 62 is decremented to reflect the wager amount. 
[0074] The graphic depiction appearing on the screen of the color monitor 110 is then updated to the configuration 

55 shown in FIG. 16. The video ticket 164 appearing on the left hand side of the display screen 165 does not change 
between FIGS. 15 and 16; however, the box appearing on the right side of the display screen 165 is presented to 
simulate and display the closed pull-tabs 1 70 of a paper pull-tab lottery ticket. The player then has the option of se- 
quentially opening the pull-tabs 1 70 one at a time, or opening all of the pull-tabs 1 70 at once. In order to further simulate 
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a paper pull-tab lottery ticket, the slave terminal 16 wiil produce a ripping sound as the screen displays the pull-tabs 
170 being slowly opened (FIG. 17). As shown in FIG. 17. the pull-tabs 170 will remain open as if they were peeled 
away from the video ticket 164 appearing on the display screen 165. 

[0075] After the pull-tabs 170 have been opened, the slave temninal 16 scans the data received from the master 
processing unit 1 4 with each video ticket 1 64 to detemnine if the ticket 1 64 includes any winning combinations. In the 
preferred embodiment, since all tickets 1 64 have previously been tabulated and identified by the central game processor 
1 2. the slave terminal 1 6 simply scans the data received from the master processing unit 1 4 to detect the presence of 
a winning combination. Such combination is identified by the central game processor 12 at the time tickets are input 
Into the system (described above) by preferably setting a bit in the video ticket data packet sent to the slave tenninal 
16. Upon detection of the set bit, the slave terminal knows a winning combination has been purchased. If a winning 
combination is detected, the slave terminal 16 reads and displays the amount won in the lower portion of the display 
screen 165 as illustrated in FIG. 17. Any amount won is added to the CREDITS field 162 appearing on the screen. 
After a short delay, the screen reverts back to the display shown ir FIG. 14. This sequence of play, and the associated 
screen displays, continues until a player exhausts all of his or her credits, or until the player depresses the Cash Out 
pushbutton 172 (FIG. 14). 

[0078] After the Cash Cut pushbutton 1 72 has been depressed by a player, a validation ticket is printed with a vali- 
dation number received from the master processing unit 1 4. In a preferred embodiment, the player may then take this 
validation ticket to a cashier in order to redeem any prizes or money won. 



V. System Implementation 

[0077] In a preferred embodiment of the invention, the local area network 20 connecting the slave tenninais 16 to 
the master processing unit 14 is an Ethernet network employing the Ethernet 802.3 protocol. To communicate, each 
side (i.e.. each slave terminal 16 or master processing unit 14) must lock a record transmitted over the network 20 
before attempting to read or write it. The recipient must then unlock the record when It is finished. Communication 
between the slave terminals 1 6 and the master processing units 1 4 is thus controlled through software running on each 
component. 

[0078] A listing of the definitions of the programs used in a preferred embodiment of the gaming system 1 0 appears 
below. The files designated are stored in either the central game processor 12, the master processing units 14 or the 
slave terminals 16 depending upon the file type and its usage. 





Configuration Files 


SITE.CFG 

USER.CFG 

OPTION.CFG 

SLAVE.CFG 

GAME.MAP 


site specific information: name, phone number, etc. 
users and passwords 
configurable options 

state of slave temninals (enabled or disabled) 
relates pools to active games 





Report Files 


EVENTLOG 

STATUS.RPT 

AUDlTxx.RPT 


sequential record of key system events 

cun-ent system status 

status of all the slave temninals 16 



[0079] Four files are also provided for each pool of game tickets, which identify the game serial number and 
scription of the aspects of each game. These game files are set forth below. 





Game Files 


FORMxxxx.CFG 
FORMxxxx.HDR 
FORMxxxx.DEF 
FORMxxxx.DST 


game configuration infomnation, (i.e., rows, size, etc.) 
header file for no. of winning ticket combinations and amounts 
ticket definitions and symbols 
ticket distribution (I.e., how many of what type) 
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Validation Files 


VALIDATE.REC 
VALIDATE.STT 


50 validation records (assigned and free) 
validation state (nriost recent seq # & date) 





Other Files 


AUDIT.PTG 
CMDRSRPTG 
GAMHDRxx.PTG 
SYSMSG.PTG 


File of 20 records containing audit information about each slave temninal 16. 

File of 20 records containing command/response block for each slave tenninal 1 6. 

File of the Game Header, where xx=01-12 depending on game number. 

File of messages for slave terminal 1 6 and master processing unit 14. Each record is 80 bytes 

long, and is indexed by record number. 



[0080] In the preferred embodiment of the invention, software is provided at the central game processor 1 2 to convert 
the raw symbol data entered by the operators into the video ticket data mentioned above. For example, one file, CVTPTI. 
EXE, is employed to convert the raw symbol data into the four game files identified above. 

[0081] Set forth in Table 1 Is a prefen-ed configuration of an audit record prepared by the master processing unit 14 
to be completed for each of the slave temiinals 1 6. The record appearing in Table 1 represents 1 of 20 such sequential 
records arranged in the file AUDIT.PTG for each slave terminal 16 coupled to the LAN 20. 



TABLE 1 



Byte 


Description 


00 


MM 


(BCD) Date 




01 


DD 


(BCD) Initialized 




02 


YY 


(BCD) Gregorian Format 


03 


HH . 


(BCD) Time 




04 


MM (BCD) Initialized 


05 


SS 


(BCD) (24 Hr Fonnat) 




06 


Total Tickets Played (BCD Digits 5,4) 


M 


07 


Total Tickets Played (BCD Digits 3,2) 


A 


08 


Total Tickets Played (BCD Digits 1 ,0) 


S 


09 


Total Coins In 


(BCD Digits 5,4) T 




OA 


Total Coins In 


(BCD Digits 3,2) E 




OB 


Total Coins In 


(BCD Digits 1 ,0) R 




00 


Total Bills In/4 


(BCD Digits 5,4) 




OD 


Total Bills tn/4 


(BCD Digits 3,2) 




OE 


Total Bills In/4 


(BCD Digits 1,0) M 




OF 


Total Bet 


(BCD Digits 5,4) E 




10 


Total Bet 


(BCD Digits 3,2) T 




11 


Total Bet 


(BCD Digits 1,0) E 




12 


Total Won 


(BCD Digits 5,4) R 




13 


Total Won 


(BCD Digits 3.2) 




14 


Total Won 


(BCD Digits 1.0) 




15 


Total Cashed Out 


(BCD Digits 5.4) 




16 


Total Cashed Out 


(BCD Digits 3.2) 
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TA8LE 1 


(continued) 




Byte 


Description 


17 


Total Cashed Out 


(BCD Digits 1 .0) 




18 


(Reserved) 


19 


(Reserved) 


1A 


(Reserved) 


1B 


(Reserved) 


1C 


(Reserved) 


ID 


(Reserved) 


IE 


(Reserved) 


1F 


(Reserved) 


20 


MM 


(BCD) Date 




21 


DD 


(BCD) Initialized 




22 


YY 


(BCD) Gregorian Format 


23 


HH 


(BCD) Time 




24 


MM 


(BCD) Initialized 




25 


SS 


(BCD) (24 Hr Format) 




26 


Total Tickets Played 


(BCD Digits 5,4) 


P 


27 


Total Tickets Played 


(BCD Digits 3.2) 


E 


28 


Total Tickets Played 


. (BCD Digits 1 .0) 


R 


29 


Total Coins In 


(BCD Digits 5,4) 


1 


2A 


Total Coins In 


(BCD Digits 3,2) . 


0 


28 


Total Coins In 


(BCD Digits 1 .0) 


D 


2C 


Total Bills In/4 


(BCD Digits 5,4) 




2D 


Total Bills In/4 


(BCD Digits 3,2) 




2E 


Total Bills In/4 


(BCD Digits 1 ,0) 


M 


2F 


Total Bet 


(BCD Digits 5,4) E 




20 


Total Bet 


(BCD Digits 3,2) T 




21 


Total Bet 


(BCD Digits 1,0) E 




22 


Total Won 


(BCD Digits 5,4) R 




23 


Total Won 


(BCD Digits 3,2) 




24 


Total Won 


(BCD Digits 1,0) 




25 


Total Cashed Out 


(BCD Digits 5,4) 




26 


Total Cashed Out. 


(BCD Digits 3,2) 




27 


Total Cashed Out. 


(BCD Digits 1,0) 




28 


(Reserved) 


29 


(Reserved) 


2A 


(Reserved) 


28 


(Reserved) 


2C 


(Resen/ed) 
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TABLE 1 (continued) 



1 Byte 


Description 


1 2D 


(Reserved) 


1 


(Reserved) 


1 


(Reserved) 



[0082] Set forth in Table 2 is a sample game file used in the preferred embodiment of the gaming system 10. Each 
game file contains the necessary parameters to define each game. The first symbol (Symbol #1) provided in the game 
file is the symbol that appears in the upper left-hand corner of the video ticket 164 displayed on each color monitor 
110 (see FIGS. 15-17). In the prefen-ed embodiment, the gaming system 10 also includes headers for each game 
offered on the system. Each game header is stored in a separate file called GAMHDRxx.PTG. where "xx" represents 
the game number. 



TABLE 2 



Byte 


Description 


00 


FORM NUMBER (BCD) 


FORM NUMBER (BCD) 


01 


FORM NUMBER (BCD) 


FORM NUMBER (BCD) 


02 


SERIAL # (BCD) 


SERIAL # (BCD) 


03 


SERIAL # (BCD) 


SERIAL # (BCD) 


04 


SERIAL # (BCD) 


SERIAL # (BCD) 


05 


SERIAL # (BCD) 


SERIAL # (BCD) 


06 


CREDITS PER TICKET (1-4) HEX 


07 


(Reserved) 


08 


(Reserved) - 


09 


(Reserved) 


OA 


(Reserved) 


OB 


(Reserved) 


OC 


(Reserved) 


OD 


(Reserved) 


OE 


(Reserved) 


OF 


(Reserved) 


10 


# of Symbols/Window (BCD) 


# of Windows (BCD) 


11 


# of Total Symbols used in the Game (Hex) 



[0083] The form number end serial number for each game appears at the top of each header file at locations OOH 
and 01 H. The form number for each game is preferably three digits; the unused bit in the file is thus zero-filled. For 
example, Form #720 would be entered as "07-20". The serial number is handled in the same manner 
[0084] Referring to FIG. 18. the four files listed above under the Other Files designation consist of files used for 
communication between the master processing units 14 and the slave tenninals 16. As shown in FIG. 18, the file 
CMDRSP.PTG 1 80 comprises a record of the commands and responses received ortransmitted by each slave terminal 
1 6. Each slave terminal 1 6 reads commands written to this file by the master processing unit 1 4, and each slave temninal 
16 writes its response to this file to be read by the master processing unit 14. The location of this file in the master 
processing units 14 is identified in FIG. 1 9 (Command Queues 208). A detailed description of the preferred commands 
and responses employed on the gaming system 10 is provided below. 

[0085] The file AUDIT. PTG 1 82 comprises a record of the status for each slave temninal 1 6. Slave terminal 1 6 status 
is written to the file by each slave temiinal 1 6 on command from the master processing unit 14. The infomnation stored 
in this file is processed by the master processing units 14 to generate the audit report for the system administrator. 
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ro0861 AS Shown in FIG. 18, both the SYSMSG.PTG 184 tile and the GAMHDRxx.PTG 186 file are files employed 
S a ulidi^ctional manner; data is written to each by the master processing unit: 14 to be read by the s ave temjmal 
1 6 In the file SYSMSG.PTG 1 84. system messages are stored to be broadcast on each slave temnmal 1 6 as defined 
iy t e ma ler adm^^^^^^^ Eac^ sLe terminal 16 also reads the particular <^AMHDRxx.PTG file 1 86 ne^^^^^^^^^ 
configure the slave temiinal 1 6 (or the particular game to be played. The master processing unit 14 wntes the GAM- 
HDRxx PTG files 1 86, one for each game supported, when the game is activated. 

roOSTl Referring to FIG. 19, a number of globally accessible data structures are also provided In the gaming system 

0 These structures also correspond to the Other Files listed above and are located in the memory map of each master 

orocessinq unit 14 The Game Map structure 190 consists of three records which relate games in the inventory stored 

at each master processing unit 14 to currently active games. The Game Configuration data structure 1 92 also consists 

of three records that provide detailed infomiation about the active games on the systenri. The Game Configurat on 

structure 192 thus Includes the game name, iom number, size, number of rows and cdumns, symbols numbe of 

tickets remaining in the pool, the shuffled pool itself, and ticket definitions. There is also a Network State structure 194 

that stores a representation of the state of each master processing unit's 1 4 local area network 20. 

0088] Data structures are also provided for validation and user identiflcation. Two structures de ine the Val.da t on 

Numbers 1 96 supplied when a player cashes out. as well as the Validation State 1 98. The Validation Numbe^ 1 96 

consist of 1000 records comprising the outstanding validation numbers provided to players who have ^^^^ed out as 

well as the remaining unasslgned numbers. The Validation State 1 98 lists the next sequence number for a va» 

ticket and a modified Julian date. The User file 200 consists of ten records including th^"f^^^; P^^^*°^^^ .^"'^J'^^^^^^^ 

levels of each administrator, as well as unasslgned numbers. A data structure also exists for the ^^-^^ ^^^^^^^^^^ 

[0089] Other structures in the gaming system 10 include a file for master processing unit 14 °Pt'°"s. J® ^^^^^ °' 

each slave temilnal 1 6 and command queues. The Master Option file 204 contains configurable options such as show 

cards bmadcast winners and shut down Information. The Slave State records 206 describe the status of each slave 

^emiinal 16 with respect to the command/response cycle. The Command Queue 208 ,s a storage record fo slave 

temilnal commands including audit, shut down, reset and broadcast infomiation. and is used in conjunction with the 

CMDRSP.PTG file 180 shown in FIG. 18. . j .,i.«„„„t„r 

[0090] lnonepreferredembodimentofthegamingsystem10.amenuofcommands/optionsisprovidedattheni^^^^^^^ 

processing units 14. Afterthe gaming system 1 0 is initialized and the master administrator has '^o'^P'^ted logg ng onto 
the master processing unit 1 4, a menu routine is executed. The main options available on the menu incUide validation/ 
admTniSration commands. reporting functions and system service options. Commands displayed on the menu corre- 
sDond to the programs and data files described above. . .. u*i .«.«^.*Kor, 

[0091] in one embodlment. the game symbols displayed on the back of a video ticket 164 are slightly larger than 

hose displayed on the front of the ticket 164, As a resuft. two sets of symbol defln ions are ^^'^^^^^'t^^^^ 
lnthisemboLent,afilelabeledFORMxxxx.FACincludesthegraphicsfortheticketfaceandafnelabeedFOR^ 

BACcontainsthegraphicsforthe back of the Video ticket164.Athirdfile.FORMxxxx.PAL. includes palette definrt^^^^^^^ 
r00921 As mentioned, the color monitor 110 displays the numberof tickets 1 64 remaining in each game being played 
n a field 1 68 appearing on slave temiinal color monitor 110 (FIG. 14). For each play that turns up a winner, therefore^ 
a message in the form "WIN $XXX" appears on each color monitor 1 1 0. The game's six digit senal number also appears 

lo09Z] ''°Jn edlTmecSm is prefembly provided to allow up to six messages to be communicated beNveen each 
rnasterprocessingunit14andtheslavetem,inals16asdefinedinconnectionwiththeCMDRSP^TGW^^^^^^^^ 
implementation, each message is assigned a number from one to six. Further examples of the substanc^^^^^ such 
messages include: (1) "The facility is going to close"; (2) broadcast Infomiation about a winrier; (3) T^^'^ket level loV 
(4)aparticulargameisnowclosed;and(5)"Weareclosed...Goodnight".Themasteradministratorcontrolsd,stnbut.on 

of these messages to each of the slave temiinals 1 6 via the files defined above. 

[0094] As stated, the master administrator also has access to some options that may be tumed on or off as the 
administrator desires. Options accessible to the administrator are defined in the Master Options data structure 204 
(FIG. 19), and include for example: (1) whether the slave temilnal 1 6 displays to the player he nur^ber of P^aV^ re- 
maining n a game; (2) whether winning ticket amounts are broadcast to other slave temiinate 16; (3) the amount of 
S^l ln which to disp ay the closing announcement; (4) whether the low ticket level message shou d be broadcast and 
iiso,atwhat percentage of plays remaining; and(5)whetherthe optional printer88 is attached to the master computer 

[0095? Depending on whether the optional printer 88 Is coupled to the master computer 70. the "taster administrator 
\s capable of sending reports both to the printer 88 or to the monitor 82 (FIG. 5). Audit infomiation is fust d^^Playe J or 
printedforeachslavetem,inal16.andthenasummaryofallslavetem,inal16infom,ationisprov,ded.Th^^^^^^^ 
can also be communicated over the modem 24 to the central game processor 12 in a preferred embodiment. Table 3 
contains a general listing of the information contained in the audit reports. 



14 
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Table 3 



Game ID/Serial No. 


Each Slave Tenminal 16 


Serial Number 
Plays Remaining 
Date/Time of Report 
Amount Left to Win 


Game ID or serial Number 
Starting Plays 
Plays Remaining 
Audit Information 



Infomiation included for each slave temninal 16 includes the date and time the slave terminal 16 was initialized, the 
number of video tickets 1 64 played, the number of coins and bills received, the total amount bet and won, and the total 
amount cashed out. 

[0096] The master administrator can preferably disable a game from the master processing unit 14 at any time. In 
addition, the master administrator can queue games to be automatically loaded after the game pool currently played 
is exhausted. If games are queued in this manner, the succeeding game will share the same form number as the game 
currently being played so that new game symbols need not be down-loaded to the slave tenninal 1 6 while the game 
is in progress. Thus, the master administrator is capable of observing the status of the games being played, and also 
which games remain in the inventory of games stored at the master processing units 14. Games listed in the inventory 
are, therefore, turned on and made active by the master administrator. 

[0097] The following tasks can be periomned on-line at the master processing units 1 4, while games are being played: 
(1) display game status; (2) display slave terminal/network status; (3) disable a game; (4) display inventory; (5) edit 
system messages; and (6) queue like forms. The following tasks are perfomned off-line: (1) display/change system 
options/flags and send broadcast infomnation; and (2) set up service/site infomriation within a file. 
[0098] Table 4 includes a preferred listing of the commands used in a preferred embodiment of the gaming system 
10. As described above, commands are transmitted from the master processing units 14 to the slave temninals 16. 
Responses are transmitted from the slave terminals 16 to the master processing units 14. 



Table 4 



Command 


Definition 


CMD01 


Transmit Status/Tickets Total & Remaining 


CMD02 


Receive Ticket/Symbol Definitions 


CMD 03 


Receive Validation # and $$$ Amount 


CMD04 


Receive Network Broadcast Information 


CMD 05 


Power Down Sequence 


CMD 06 


Copy Slave Audit Info, to AUDIT record 


CMD 07 


Requested Ticket Cannot Be Sent-Pool Empty 


CMD 08 


Initialize All Meters 


CMD 09 


Initialize Period Meters only 


CMD 10 


Request Denied 


CMD 11 


Force Down Sequence 


CMD 12 


Restart Unit 



[0099] Responses to the commands identified in Table 4 are set forth in Table 5. Responses to Commands #2, #3, 
#4 and #5 should be Response #1 indicated in Table 5. The response to Command #1 can be any of the responses 
appearing in Table 5. 



Table 5 


Response 


Definition 


RESP 01 


All is well 


RESP 02 


Send a new ticket 


RESP 03 


Send a validation Number 


RESP 04 


Winning Ticket Just Displayed 


RESP 05 


Power down acknowledge 


RESP 06 


Send temporary validation number 
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10 



15 



20 



25 



[0100] Command #4 is the broadcast message command initiated at the master processing unit 14. The contents 
of the message to be displayed will have been previously defined and stored on the master processing unit 14 (in file 
SYSMSG.PTG 184). Command #5 is a power-down sequence command. In response to Command #5, the slave 
terminals 16 should display an appropriate message to the player, such as "PLEASE CASH OUT... WE ARE SHUT- 
TING DOWN IN ( ) MINUTES ..." After Command #5 has been sent, no more credits can be purchased. When the 
cash out transaction is completed, the slave temnlnals 1 6 should be placed out of service, i.e., not allowing any additional 
plays to be purchased or money to be inserted. 

[0101] As mentioned, each master processing unit 14 requests status infomnation from each slave tenriinal 16. Com- 
mand #6 has been reserved for this purpose. In response to Command #6. the slave terminals 1 6 update the appropriate 
record in the AUDIT.PTG 182 file, and conclude with Response #1 . The master processing unit 14 will then collate this 
data and display or print it for the system administrator. 

[01 02] Commands #7 and #8, when issued by the master processing unit 1 4, cause the slave tenninats 1 6 to dear 
the appropriate software meters 64. A detailed description of the commands and data communicated over the local 
area network 20, and the responses received, appears below. 

A. Command #1 : Update Your Status 

[0103] This command from the master processing unit 14 allows the slave temninal 16 to: 

1 . Request a video ticket; 

2. Request a Validation Number; 

3. Know the total play count of a poo! (BEGIN); or 

4. Know the current play count of a pool (LEFT). 

5. Transmit status. 

Data Packet 



30 



35 



40 



45 



Transmit Status: 



OOHex - FFHex 
II 

It 

II 

II 



UNIT NUMBER 
Command OIH 
Response OOH 



Game Number (Ol-OC) 
Total plays byte 1 
Total plays byte 2 
Total plays byte 3 
Total plays byte A 
Total plays byte 5 
Total plays byte 6 
Plays remaining byte 1 
Plays remaining byte 2 
Plays remaining byte 3 
Plays remaining byte 4 
Plays remaining byte 5 
Plays remaining byte 6 
I 
I 
I 

00 



CMD byte 


1 


CMD byte 


2 


CMD byte 


3 


daca 


04 




data 


05 




data 


06 




data 


07 




data 


08 




data 


09 




data 


OA 




data 


OB 




data 


OC 




data 


OD 




data 


OE 




data 


OF 




data 


lOH 





data 53H 



50 



[01 04] For example, if Game #5 started with 3600 plays, and had 290 left, the data bytes would be filled out as follows: 



55 



16 
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V 





05 


Hex 


(Game t) 


; data 


01 


OOHex - FFHex 


10 


Hex 


(Start ) 


; data 


02 


ft 


OE 


Hex 




[ data 


03 


It r 


00 






data 


o; 


•t • 


00 






; data 


05 


tt 1 


00 






! data 


06 


II 1 


00 






1 data 


07 


II ' 


01 


Hex 


(Plays 


; data 


08 


11 i 


22 


Hex 


left) 


1 data 


09 


II * 


00 






i data 


04 


ti I 


00 






! data 


05 


" : 


00 

1 






1 data 


06 


11 1 


00 






; data 


53 



II 



20 B. Response #1 : All is well 

[01 05] This response indicates to the master processing unit 1 4 that the slave tenninal 1 6 is operating normally, that 
a play has not been requested, and that a validation number is not required at this tine. This is the correct response if: 



25 



30 



1 . A video ticket has been successfully received; 

2. A validation number has been succesfully received; 

3. Meters have been successfully cleared; 

4. The requested message has been displayed; or 

5. Audit information Is ready. 

Nomially, for the program to transmit this response, it will be in response to Command #1 . 



Data Packet 



35 



40 



45 



50 



55 



All Is Well^ 



Unit Number 
Command 
Response 01 



00 



CMD byte 


1 


CMD byte 


2 


CMD byte 


3 


data 


04 




data 


05 




data 


06 




data 


07 




data 


08 




data 


09 




data 


OA 




data 


OB 




data 


DC 




data 


OD 




data 


OE 




data 


OF 




data 


010 




data 


53H 
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C. Command #2: Receive a Video Ticket/Symbol Definition 

[0106] This command from the master processing unit 1 4 results when a slave terminal 1 6 has previously transmitted 
the "SEND A TICKET" (Response #2) response. It allows the slave temninal 16 to receive and evaluate a new play 
5 from the requested pool of game plays. The Tabs and symbol windows (Wind) are defined as follows: 



10 



15 



20 



25 



30 



35 



40 



45 



50 



\ Tab1 
, wina 1 


Tab1 


Tab1 
vvinuo 


Tab1 


Tab1 

\A/inHC^ 

vvinuo 












; Tab2 

1 WinH 1 


Tab2 
Wtnd2 


Tab2 
Winds 


Tab2 
Wind4 


Tab2 
Winds 












] Tab3 
1 Wind 1 


Tabs 
Wind2 


Tabs 
Winds 


Tabs 
Wind4 


Tabs 
Winds 












1 Tab4 
1 Wind 1 


Tab4 
Wind2 


Tab4 
Winds 


Tab4 
Wlnd4 


Tab4 
Winds 












1 Tabs 
I Wind 1 


Tabs 
Wind2 


Tabs 
Winds 


Tabs 
Wind4 


Tabs 
Winds 



[0107] If no window or tab exists for a particular game, the data should be set to DC, e.g., a S-tab ticket with only S 
windows per tab. 



55 
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Data Packet 



5 Receive a Play 



OA 



10 



15 



20 



25 



30 





Unit Number 


; CMD byte 


1 




Command 


02 




; CMD byte 


2 




Response 






; CMD byte 


3 


Cane Number 


(01-OC) 


; data 




Tab 


1 Window 


/ 


01 


1 data 05 




Tab 


1 Window 




02 


1 data 06 




Tab 


1 Window 


# 


03 


j data 07 




Tab 


1 Window 




04 


! data OS 




Tab 


1 Window 




05 


\ data 09 




Tab 


2 Window 




01 


1 data OA 




: Tab 


2 window 


# 


02 


' Ha^a OB 




i Tab 


2 window 




03 


J data OC 




: Tab 


2 window 


M 

jr 


04 


J data OD 




; Tab 


2 Window 




05 


1 data OE 




Tab 


3 Window 




01 


; data OF 




Tab 


3 Window 


# 


02 


; data 10 




Tab 


3 Window 




03 


: data i: 




, Tab 


3 Window 




04 


i data 12 




; Tab 


3 Window 




05 


; data 13 




; Tat> 


4 Window 




01 


; data 14 




! Tab 


4 Window 




02 


; data 15 




Tab 


4 Window 




03 


1 data 16 




; Tab 


4 Window 


# 


04 


; data 17 




: Tab 


4 Window 


f 


05 


1 data 18 




; Tab 


5 Window 


f 


01 


1 data 19 





Tat 5 Window # 02 


1 data 


lA 


Tab 5 Window # 03 


1 data 


IB 


Tab 5 Window # 04 


; data 


IC 


Tab 5 Window # 06 


1 data 


ID 


Win Amount xx 


{ data 


IF 


Win Amount xx 


1 data 


20 


00 


; data 


53 



45 

Symbols are ordered as follows: 
[0108] 



TAB A 


sym 01 


sym 02 


sym 03 


sym 04 


sym 05 


TABB 


sym 06 


sym 07 


sym 08 


sym 09 


sym 10 


TABC 


sym 11 


sym 12 


sym 13 


sym 14 


sym 15 


TABD 


sym 16 


sym 17 


sym 18 


sym 19 


sym 20 


TABE 


sym 21 


sym 22 


sym 23 


sym 24 


sym 25 



[0109] In a pool having five total symbols, and a game with three tabs only, assume the following correlation has 
been defined: 
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1=heart 2=club 3=spade 4=diamond 5=crown If the video ticket to be displayed looks like this: 



heart 


club 


heart 


ciub 


heart 


spade 


club 


spade 


diamond 



And the game number Is 11 : 



10 





\ Game Number OB 


Hex 


; data 


04 




i 0^ 


Hex 


1 data 


05 




1 02 


Hex 


J data 


06 




1 01 


Hex 


1 data 


07 


15 


; 02 


Hex 


! data 


08 




1 01 


Hex 


I data 


09 




! 03 


Hex 


j data 


OA 




02 


Hex 


I data 


OB 




03 


Hex 


j da -a 


OC 


20 


; 04 


Hex 


I data 


OD 




; 00 


Hex 


1 data 


OE 




; XX 


Hex 


! data 


OF 




1 XX 


Hex 


: data 


10 




I 00 


Hex 






25 


! 00 


Hex 


i data 


53 



30 



D. Response #2: Send a Ticket 

[0110] This response will be transmitted to the master processing unit 14 if the player has made a valid request for 
a play. In this case, the player must have credits, and must have pressed the Play pushbutton 166. 



35 



Data Packet 



40 



45 



50 



Send a Ticket: 



UnitNumber 
Conunand 
Response 02 



Game Number (Ol-OC) 



CMD byte 1 
CMD byte 2 
CMD byte 3 

data 04 
data 05 
data 06 
data 07 
data OS 

data 53 



55 



E. Command #3: Receive a Validation Number 

[01 11 ] This command from the master processing unit 1 4 is generated in response to the slave terminal 1 6 sending 
Response #3 - Request Validation Number. 
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Cata Packet 



Receive Valid. 



15 



20 



00 BCD 

00 BCD 

00 BCD 

20 Hex 



99 BCD 
99 BCD 
99 BCD 
7F Hex 



Unit Number 
command 03 
Response 



THOUSANDS 

tens: 

TENTHS 

Va 1 idat ion 
Validation 
Validation 
Validation 
Validation 
Va 1 Ida t ion 
Validation 
Validation 
Validation 
Val idat ion 
Validation 



HUNDREDS 
UNITS 

HUNDREDTHS 
number 1 
number 
number 
number 
number 
number 
number 7 
number 8 
number 9 
number 10 
number 11 



2 
3 
4 
5 
6 



CMD byte 1 
CKD byte 2 
CMD byte 3 

data 04 
data 05 
data 0 6 
data 07 
data 08 
data 09 
data Ok 
data OB 
data DC 
data 00 
data OE 
data OF 
data 
data 



10 

11 



data 53 



25 

[0112] If the master processing unit 14 sends the validation number "0234AJUN93" for the amount of $10.50, the 
packet would appear as follows: 

30 



40 



00 


BCD - 


99 


BCD 1 


00 


Hex 


i data 


04 


00 


BCD - 


99 


BCD ! 


10 


Hex 


! data 


05 


00 


BCD - 


99 


BCD ! 


50 


Hex 


1 data 


06 


00 


Hex - 


7F 


Hex ; 


30 


Hex 


1 data 


07 




II 






32 


Hex 


; data 


08 




II 






33 


Hex 


; data 


09 




II 






34 


Hex 


; data 


OA 




It 






41 


Hex 


; data 


OB 




u 






4A 


Hex 


; data 


oc 




tl 






55 


Hex 


; data 


OD 




1( 






4E 


Hex 


1 data 


OE 




11 






39 


Hex 


; data 


OF 




II 






33 


Hex 


; data 


10 




It 






20 


Hex 


j data 


11 










t 


00 


1 data 


53 



50 Note that unused codes are space filled (20H). 
F. Response #3: Send a Validation Number 

[0113] This response is transmitted to the master processing unit 14 if the player has made a valid request to cash 
55 out. In this case, the player must have credits, and must have hit the Cash Out pushbutton 172. The response also 
transmits the amount being cashed out. This infomiation is preferably used by the master processing unit 14 to help 
create the validation number. 
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D.ita Packet 



Send Validation A: 



Unit Number 
Command 
Response 03 



00 


BCD - 


99 


BCD : 


THOUSANDS 


HUNDREDS . 


00 


BCD - 


99 


BCD 1 


TENS 


: UNITS 


00 


BCD - 


99 


BCD ; 


TENTHS 


: HUNDREDTHS 



CMD byte 1 
CMD byte 2 
CMD byte 3 

data 0-; 
data 05 
data 06 
data 07 
data 08 
data 09 
data OA 



data 53 



G. Command #4: Receive Broadcast Information 

[01 1 4] This command from the master processing unit 1 4 will transmit a message to one or more of the slave temninals 
16. tt will request that a message number previously stored in the slave terminal 1 6 be displayed on the screen. Up to 
two parameters can be inserted into the message. Where the message itself contains "ESC 1" or "ESC 2" characters 
the parameters are inserted in those positions. Bytes not displayed are encoded as OOH. 



Delta Packet 



Receive Message 



00 Hex - OA Hex 
00 Hex - 7r Hex 



Unit Number 
Command 05 
Response 04 



Message Number (01-OA) 
PararalByte 1 
PararolByte 2 
ParatnlByte 3 
ParamlByte 4 
ParamlByte 5 
ParamlByte 6 
Param2Byte 1 
Param2Byte 2 
Param2Byte 3 
Param2Byte 4 
Param2Byte 5 
Param2Byte 6 



CMD byte 
CMD byte 
CMD byte 

data 04 
data 0 5 
data 06 
data 07 
data 08 
data 09 
data OA 
data OB 
data OC 
data OD 
data OE 
data OF 
data 10 

data 53 



[0115] If message #5 was previously defined to be: 

"We have a winner of $ESC 1 on MegaTab $ESC 2111" and the message to be displayed is: 
"We have a winner of $100 on MegaTab 2511!'* 

Then the following would be transmitted: 
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05 Hex 


{ data 


01 


31 Hex 


; data 


02 


30 Hex 


; data 


03 


30 Hex 


; data 


04 


00 Hex 


; data 


05 


00 Hex 


; data 


06 


00 Hex 


' r) ^ a 

1 ua 


n 1 
u / 


32 Hex 


; data 


06 


35 Hex 


1 data 


09 


21 Hex 


; data 


OA 


21 Hex 


; data 


OB 


21 Hex 


; data 


DC 


00 Hex 
1 


; data 


OC 


00 


! data 


53 



20 



[0116] Note that in this case, nulls (00 Hex) are used if that byte should not be displayed. 
H. Command #5: Power Down Sequence 

25 [0117] This command from the master processing unit 14 requests the slave temninal 1 6 to issue a "We are about 
to power down, please press cash out!" message. It will allow up to one parameter to be inserted into the message, 
e.g., the time until Power Down. 



30 



35 



40 



Data Packet 



Power Dov/n 



00 Hex - FF Hex 



Unit number 
Comniand 06 
Response 



Remaining (MSB-HI) 
RtiTTiaining (MSB-LO) 



aoove is in seconds, 
fron 0000 to FFFF 



CMD byte 1 
CMD byte 2 
CMD byte 3 

data 04 
data 05 
data 06 
data 07 
data 03 
data 09 
data OA 
data OB 



data 53 



[01 18] For example, if the Power Down time is five minutes ahead of when it actually will happen, then the following 
packet would be transmitted: 

50 



55 
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10 



00 Hex 



FF Hex 



01 Hex 
2C Hex 



above is in seconds, 
12CH- 300 = 5 minutes 



data 01 
data 02 
data 03 
data 04 
data 05 
data 06 
data 07 
data 08 
data 09 
data OA 
data OB 



data 53 



20 



I. Command #6: Update Audit Information 

[01 1 9] This command from the master processing unit 1 4 requests the slave temninal 1 6 to update its audit information 
located in file AUDIT.PTG 182. 



25 



Delta Packet 



30 



Aud: 



Information 



Unit Number 
Command 06 
ResDonse 



00 



CMD byte 1 
CKD byte 2 
CKD byte 3 

data 53 



35 



J. Command #7: Requested Play Cannot Be Sent-Pool Empty 

[0120] This command from the master processing unit 14 informs the slave terminal 1 6 that the last play recannot 
40 be filled. 



Data Packet 



45 



50 



Deck Empty: 



Unit number O 
Command 07 
Response 



Game Number (01-OC) 



CMD byte 1 
CMD byte 2 
CMD byte 3 

data 04 
data 05 
data 06 
data 07 



55 



data 53 
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K. Response #4: Winning Play Ticket Just Displayed 

[01 21 1 This response indicates to the master processing unit 1 4 that a slave terminal 1 6 has just displayed a winning 
play. (It is up to the administrator to decide whether to display this information.) 

D.ata Packet 



I've Wonl ! : 



Unit Nunber 
Con^mand 
Response 04 



00 BCD - 99 BCD 
CO BCD - 99 BCD 
0 0 BCD - 99 BCD 



THOUSANDS 

TENS 

TENTHS 



HUNDREDS 
UNITS 

HUNDREDTHS 



CMD byte 1 
CMD byte 2 
CKD byte 3 

datd 04 
data 05 
data 06 
data 07 



[0122] Table 6 includes a list of the make and model of elements employed in the presently preferred embodiment 
of the gaming systen 10. 

Table 6 



Ref. # 


Item 


Description 


Manufacturer 


20 


Local area network 


Lantastic 


Artisoft, Inc. 


44 


Keyboard 


Type 101 


Keytronics 


136 


Printer 


Laser Printer 


Epson America, Inc. 


112 


Printer 


40-column printer 


Star Micronics, Inc. 


(N/A) 


Bios type 


Basic I/O System 


American N/legatrends, Inc. 


146 


Sound generator 


AY-3-8940 


Yamaha Corp. 


148 


Dariington Drive 


UNL-2003A 


Motorola, Inc. 


80 


LAN Interface 


Lantastic 


Artisoft, Inc. 


102 


LAN Interface 


Lantastic 


Artisoft, Inc. 


86 


Keyboard 


Type 101 


Keytronics 



[01231 There has been described a computerized gaming system that provides fixed pools of games to be played 
by players on the system. According to a prefen-ed embodiment of the invention, the gaming system is distributed 
between a central game processor, master processing units and slave terminals. The fixed pools of game plays are 
created at the central game processor and downloaded to the master processing units upon request. Through the 
slave terminals, players can purchase game plays from each fixed pool of plays received and stored at the master 
processing unit to which the slave is attached. 

[0124] In the preferred embodiment, a game play corresponds to a video representation of a paper pull-tab lottery 
ticket As in the paper pull-tab lottery game, a predetemiined number of winning and losing tickets is established for 
each pool of game plays. Also, a predetermined dollar value for winning plays Is included with each game pool. Ac- 
cording to the invention, therefore, each player can purchase game plays from the entire fixed pool being stored at the 
master processing unit to which a slave terminal is connected. Since multiple slave temiinals are contemplated for 
connection to each master processing unit, a single player may compete against other players located at similar slave 
temiinals to purchase as many of the winning tickets In each fixed pool as possible. 

[0125] The gaming system described above thus combines the advantages of paper lottery and wagering games 
with the popularity and attractiveness of the video game. As described, each player can compete directly with other 
players for the purchase of winning plays, thus providing an element of competition over the prior paper pull-tab lottery 
games Since it is contemplated that slave temiinals may be located either within the same location or remotely from 
one another players can also compete with other players both locally and across great distances. The excitement, 
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10 



sounds and visual display inherent in a video game provides further attraction of the computer gaming system over 
the prior paper lottery type games. 

[0126] The invention accordingly also provides a gaming system comprising: 

a master processing unit having a memory device operative to store at least one fixed pool of game plays, each 
fixed pool having a predetenmined number of winning plays; and 

a plurality of slave terminals, each slave tenninal coupled to communicate with the master processing unit and 
having a player-controlled selection device, each player-controlled selection device operative to request game 
plays from said fixed pool of game plays stored at the master processing unit. 



[0127] In the gaming system defined above, a plurality of players can simultaneously operate the player-controlled 
selection devices provided on the plurality of slave temriinals to purchase game plays from the entire fixed pool of game 
plays stored at the master processing unit 

[01 28] The gaming system may further comprise a local area network for coupling the slave temninals to the master 
15 processing unit. 

[0129] Each slave terminal may further comprise a processing element, a display, a local area network interface, 
and a wager deposit device. 

[0130] The processing element may comprise a personal computer. 
[0131] The player-controlled selection device may comprise a push-button. 
20 [0132] The master processing unit may comprise a personal computer. 

[0133] The master processing unit may comprise means for maintaining a record of the number of plays selected at 
each slave terminal from each fixed pool of game plays and the number of plays remaining in each fixed pool of game 
plays stored at the master processing unit. 

[0134] The gaming system may further comprise a central game processor for generating the fixed pools of game 
25 plays, and a communication interface operative to supply the fixed pools of game plays to the master processing unit. 
[01 35] The central game processor may comprise means for supplying a new fixed pool of game plays to the master 
processing unit upon exhaustion of each fixed pool of game plays stored at the master processing unit. 
[0136] The central game processor may comprise means for maintaining a record of the number of game plays 
remaining in each fixed pool of game plays and the number of winning plays remaining in each fixed pool of game plays. 
30 [0137] The communication interface may comprise a telephone link, and the central game processor and master 
processing unit each comprise a modem. 

[0138] The central game processor may further comprise a personal computer. 
[0139] Each game play may comprise an electronically simulated pull-tab lottery ticket. 

[0140] The invention also provides a gaming system comprising means for storing at least one fixed pool of game 
35 plays, each fixed pool having a predetemnined number of winning plays; and 

a plurality of slave means, coupled to the storing means, for requesting game plays from each fixed pool of game 
plays stored in the storing means. 

[0141] The invention may also provide a gaming system comprising: 

40 a master processing unit having a memory device operative to store at least one fixed pool of game plays, each 

fixed pool having a predetermined number of winning plays; 

a plurality of slave tenninals, each slave terminal having a player-controlled selection device operative to request 
game plays from each fixed pool of game plays stored at the master processing unit; and 
a communication interface for coupling the stave temninals to the master processing unit. 

45 

[0142] The communication interface may comprise a local area network. 
[0143] The invention may also provide a gaming system comprising: 

a central game processor for generating a plurality of fixed pools of game plays, each fixed pool having a prede- 
50 termined number of winning plays; 

a plurality of master processing units, each master processing unit coupled to the central game processor through 
a communication interface to receive the fixed pools of game plays from the central garne processor and having 
a memory device operative to store at least one fixed pool of game plays; and 

a plurality of slave terminals coupled to communicate with each master processing unit, each slave tenninal having 
55 a player-controlled selection device operative to request game plays from the fixed pool of game plays stored at 

the master processing unit. 
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Claims 

1. A gaining system (10) comprising: 

a central gaming processor (12) an-anged for fixed pools of game plays to be created thereat; 
master processing units (14) and slave tenminats (16) in communication therewith, the central gaming proc- 
essor (12) being arranged to download the fixed pools on request to the master processing units (14); 
the slave terminals (16) comprising a player-controlled selection device (128) to allow game plays to be pur- 
chased by a player from the entire fixed pool of game plays stored at each master processing unit (14), and 
a player interface (110, 120) to indicate to the player if the game play purchased from the master processing 
unit (14) constitutes a winning play. 

2. The system of claim 1 , in which the central gaming processor (1 2) is an-anged for fixed pools of game plays having 
a predetermined number of winning game plays to be created thereat. 

3. The system of claim 1 or claim 2, in which the central gaming processor (12) and the master processing units (14) 
are each provided with a modem (22, 24) to permit downloading of the fixed pools from the central gaming processor 
(12) to the master processing units (14) on request. 

4. The system of any preceding claim, in which the master processing units (14) include a database (64) an-anged 
to store the fixed pool of game plays downloaded from the central gaming processor (12). 

5. The system of any preceding claim, in which the slave temninals (16) include a wager acceptor (124, 126) for 
purchasing game plays from the entire fixed pool thereof. 

6. The system of any preceding claim, in which, in response to an input to the player controlled selection device (1 28) 
the stave terminals (16) are arranged to obtain a game play from the pool of remaining game plays stored at the 
master processing units (14), the master processing units (14) in turn transmitting ticket data representing the 
purchased game play back to the slave temninals (16). 

7. The system of any preceding claim, in which the ticket data includes information regarding the winning or losing 
status of the game play. 

8. The system of claim 6 or claim 7, in which, once the ticket data representing the purchased game play has been 
transmitted back to the slave temninals (1 6) are further configured to scan the received data in response to a further 
player input to the slave temninals, and to display on the player interface (110) whether the game play is a winning 
or a losing game play. 



Patentanspruche 

1 . Spielsystem (1 0) aufweisend: 

einen zentralen Spielprozessor (12), derfur eine vorgegebene Anzahl von Spielpartien, die hiervon erzeugt 
werden, ausgefuhrt ist; 

Hauptrechnerverarbeitungseinheiten (14) und Satellitenrechnergerate (16), die damit in Verbindung stehen, 
wobei der zentrale Spielprozessor (12) ausgefuhrt ist, um die vorgegebene Anzahl auf Anfrage der Haupt- 
rechnerverarbeitungseinheiten (14) herunterzuladen; 

wobei die Satellitenrechnergerate (16) eine spielergesteuerte Auswahleinrichtung (128) aufweisen, um zu 
ennoglichen, dass Spielpartien von einem Spieler von der ganzen vorgegebenen Anzahl von Spielpartien 
erworben wird, die in jeder Hauptrechnerverarbeitungseinheit (14) gespeichert sind, und eine Splelerschnitt- 
stelle (110, 120), um dem Spieler anzuzeigen, falls die von der Hauptrechnerverarbeitungseinheit (14) erwor- 
bene Splelpartie ein Gewinnspiet darstellt. 

2. System nach Anspruch 1 , in dem der zentrale Spielprozessor (12) fiir eine vorgegebene Anzahl von Spielpartien 
mit einer vorbestimmten Anzahl von Gewinnspielpartien ausgefuhrt ist, die hiervon erzeugt werden. 
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3. System nach Anspruch 1 Oder 2, in dem der zentrale Spielprozessor (12) und jede Hauptrechnerverarbeitungs- 
einheit (14) mit einem Modem (22. 24) ausgefuhrt sind, urn ein Herunterladen der vorgesehenen Anzahl von dem 
zentralen Spielprozessor (12) zu den Hauptrechnerverarbeitungseinheiten (14) auf Anfrage zu ermoglichen. 

4. System nach einem der voranstehenden Anspruche, in dem die Hauptrechnerverarbeitungseinheiten (14) eine 
Datenbank (64) umfassen. die ausgefuhrt ist. um die vorgegebene Anzahl der von dem zentralen Spielprozessor 
(12) heruntergeladenen Spielpartien zu speichem. 

5. System nach einem der voranstehenden Anspruche, in dem die Satellitenrechnergerate (16) einen Wetteinsatz- 
empfanger (124. 126) umfassen zum Enwerben von Spielpartien von der ganzen vorgegebenen Anzahl hiervon. 

6. System nach einem der voranstehenden Anspruche, in dem die Satellitenrechnergerate (1 6) ausgefuhrt sind, um 
in Antwort auf eine EIngabe in die spielergesteuerte Auswahleinrichtung (1 28) eine Spielpartie von der Anzahl der 
in den Hauptrechnerverarbeitungseinheiten (14) gespeicherten verbleibenden Spielpartien zu erhalten, wobei die 
Hauptrechnerverarbeitungseinheiten (14) ihrerseits Ticketdaten zu den Satellitenrechnergeraten (16) zuriickuber- 
tragen, die die erworbene Spielpartie reprasentieren. 

7. System nach einem der voranstehenden Anspruche, in dem die Ticketdaten Inforation hinsichtlich des Gewinn- 
oder Veriierstatusses der Spielpartie umfassen. 

8. System nach Anspruch 6 oder 7, in dem, nachdem die Ticketdaten, die die erworbene Spielpartie reprasentieren, 
zuruck zu den Satellitenrechnergeraten (16) ubertragen wurden, des weiteren ausgebildet sind, um die empfan- 
genen Daten in Antwort auf eine weitere Spielereingabe in die Satellitenrechnergerate abzufragen und um auf der 
Spielerschnittstelle (110) anzuzeigen, ob die Spielpartie eine Gewinn- oder Verlustspielpartie ist. 



Revendlcations 

1. Syst6me de jeux (10) comprenant : 

un processeur de jeu central (12) configure pour que des ensembles d6lermin§s de combinaisons de jeux 
puissent y etre cr66s ; 

des unites princlpales de traitement (14) et des terminaux esclaves (16) communiquant avec celui-ci, le pro- 
cesseur de jeu central (12) 6tant configure pourtransmettre les ensembles determines de combinaisons k la 
demande des unites principales de traitement (14) ; 

les terminaux esclaves (16) comprenant un outil de selection (128) control^ par le joueur, afin qu'il puisse 
acheter des combinaisons de jeu choisies parmi I'ensemble determine stock6 sur chaque unite principale de 
traitement (1 4), et une interface joueur (110,1 20) pour indiquer au joueur si la combinaison achet6e & runit6 
principale de traitement (14) est une combinaison gagnante. 

2. Systeme selon la revendication 1 dans lequel le processeur de jeu central (1 2) est configure afin que des ensembles 
determines de combinaisons de jeu, contenant un nombre predetermine de combinaisons gagnantes, puissent y 
etre crees. 

3. Systeme selon Tune quelconque des revendlcations 1 ou 2 dans lequel le processeur de jeu central (12) et les 
unites princlpales de traitement (14) sont chacun equip6s d'un modem (22, 24) penmettant k la demande le teie- 
chargement des ensembles detenmines de combinaisons depuis le processeur de jeu central vers les unites prin- 
clpales de traitement (14). 

4. Systeme selon I'une quelconque des revendlcations precedentes dans lequel les unites principales de traitement 
(14) incluent une base de donn6es configur6e pour stocker les ensembles determines de combinaisons de jeux 
teiecharges depuis le processeur de Jeu central (12). 

5. Systeme selon I'une quelconque des revendlcations precedentes dans lequel les temninaux esclaves (16) com- 
portent un dispositif de paiement (1 24, 1 26), pennettant d'acheter des combinaisons de jeu issues des ensembles 
detenmines correspondants. 

6. Systeme selon I'une quelconque des revendlcations precedentes dans lequel, en reponse k une commande entree 
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dans I'outil de s6lection {1 28) contr6l6 par le joueur, les terminaux esclaves (1 6) sont configures pour recevoir une 
combinaison panmi celles restant stockees sur I'unite principale de traitement (14), laquelle transmet a son tour 
au terminal esclave (16) un bulletin representant la combinaison achet^e. 

Syst^me selon I'une quelconque des revendications pr6c6dentes dans lequel le bulletin contient des infomnations 
concernant le statut gagnant ou perdant de la combinaison. 

Syst^me selon I'une quelconque des revendications 6 ou 7 dans lequel, lorsque le bulletin representant la com- 
binaison achetee a ete transfere aux terminaux esclaves (16), ceux-ci sont k nouveau configures pour trailer les 
donnees regues en reponse a une nouvelle entree du joueur sur le temrtinal esclave, et pour afficher sur I'interface 
joueur (110) le statut, gagnant ou perdant, de la combinaison. 



29 



EP 0 907 136 B1 




30 



EP 0 907 136 B1 




Ll. 



31 



EP 0 907 136 B1 



O 



0| 



! 



a: uj 

is 



i r+ 




CtLU 

S2G: 



o 




ro 



in 




< 

"I 



2 

< ^ UJ 

P o cr 

2 2 < 

^ 2 K 

CO 2 CD 

CO 5 U 
.Ui O 



CD 
LU < 

o 




32 



EP 0 907 136 B1 




33 



EP 0 907 136 B1 



f7=S 



CD 




cr 
o 

< t: 
> o 



o 
a: 
< 
o 

CO 

>- 

UJ 



O! 



< 



x<2:ocr)X<i*:uJ 



o 

CD 



q: 

i 

UJ 
2 
UJ 

CO 



CVJ 



2 

O 
eg 



CL 



x< i 

UJ < ! 



UJ 

< 
o 



q: 
o 

to 

UJ 
CJ 

c 
cr 
a 
o 

a: 



cn 
-J 

! UJ Z 

i > O 

I CD Q 
Z 

< 
X 



< 

o: 



1 u. O 



u 
-J 

CD 

CLQ. 

q:3 
( occn 

2 o 



co 



V 



UJ 

o 



-J UJ 

< -J 

< 

Ui DC 



UJ 

> 

o 
o 

< 

X 



in 

CD 
Ll_ 



UJk 

So 



q: 

UJ 



34 



EP 0 907 136 B1 




EP 0 907 136 B1 




36 



EP 0 907 136 B1 




37 



EP 0 907 136 B1 




38 



EP 0 907 136 B1 



F1G.9C 



CRP 



^258 

i /pending command:; 

y \ RESPONSE? J 

NO 



YES 



(return) 



272 
272 



OK 



FIG. 9D 

234 236 238 



272 



I REQUEST 
i TICKET 



' ^ t 



50* 



D 

«l.00 



272 



iSET DEAL GROUP 
25"*; 50<iOR ^100 



1 SET KEY TO 
GROUP 2 



IGO TO X 
-jKEYSCAry 



274 

-276 
^278 



272 ACK 
t^, POWER 
I DOWN 





SEND 
STATUS 







TICKET 
INFO 



272 
272 



RECEIVE 

VAL 
NUMBER 



^72 



RECEIVE 

Imessagej 



^72 



i POWER J 



i DOWN 



272 





1 1 SEND 

! i AUDIT 

1 i INFO 


' 1 1 


FATAL 
. ERROR 


' ! DEAL 


EMPTY 



272 



; RESET 
iWEfERS 



272 



272 



^MASTER J 
- IS 
lONLINE 



272 



REQUEST 
VAL# 


1 i 

I 












SEND 
WIN 
INFO 




1 


i 1 



DENY 



272 
272 



DOWN 



' SEND 
A TEMP 
' VAL** 



272 



39 



EP 0 907 136 B1 



242- 



CASH 
OUT 



F1G.9E 



278 



,280 



/are there 
,any credits 



\N0 [ 



NO GO TO ^ 
IKLYSCAN, 



YES 



290- 



SET CRP TO 
REQUEST 
VAUDATIONIM 



-282 



AT SOME TIME LATER, MASTER 
Will SEND VALIDATION* TO DISPENSER 



PRINT 
VALIDATION 
TICKET 



-284 



CLEAR 
CREDITS 



■28.6 



288 



GO TO V 
DEMO MODlj/ 



; OPEN 

F1G.96 ^ 



t1 



246 



300 



298 



OPEN WINDOW AND 
DISPLAY SYMBOLS 



GOTO 
KEYSCAN 




'^%/INDOWS" 
.OPEN' 



YES 



•298 



302 



INCREMENTS 
CREDITS 



I DISPLAY 
i WIN ROUTINE 



304 



'306 



I 60 TO 
"1 KEYSCAN 



FIG. 9F 



CANCEL 



^244 



'292 



IS TICKET 
'FACE BEING, 
^DISPLAYED? 




\yes goto \ 

3,7^ SELECT > 
^ IVALUEX 



294 



FIG. 9H 



SELECT 



-248 



308 



DISPLAY FACE 
OF NEXT TICKET 
IN DEAL GROUP 



310 



i ' 60 TO \ 
;•KEYSCA^y> 



FIG. 91 



/^ToiNTiuT 

INTERRUP 



— 312 



1 INCREASE 
i CREDITS 



•.RETURN) 



3!4 



3!6 



\ 



40 



EP 0 907 136 B1 



FIG.IOA 



AEN 



RESET 




41 



EP0 907 136 B1 



FIG.lOB 



SOUND 
INPUTS 



POOR > 



iB\LL > 

^probe: > 




74LS 245 



RP3 4.7K 



42 



EP 0 907 136 B1 




43 



EP 0 907 136 B1 




44 



EP 0 907 136 B1 



FIG. I3A 




45 



EP 0 907 136 B1 



FIG. 13B 



OOOP 
CI N - 




46 



EP 0 907 136 B1 



FIG. 14 



CREDITS: 04 TICKETS LEFT: 2456 

Sea ^i€8 



(FLARE SCREEN OR ATTRACT DISPLAY) 



^160 

ccccctcicicutcrrcccicccitttciucccicccmccctutictccLccci 

[[.... CONGRATULATIONS TO THE PLAYER ON MACHINE 2 1 \\ I C 

[cutc[uircttct[tccirtcrr(ctcrc[ccticcccLUC[itcccct[ci[ti 



r'A'i \"b"\ r c I ID! I E I 



PRINT 




cancel! 


OPEN 




SELECT 




PLAY 


TICKET 






ALL 











172- 



IS6' 



FIG. 15 

/ CREDITS : 04 



A 


A A 


$200 






4 WINNERS 


A 


A B 


S ISO 






6 WINNERS 


A 


A C 


$100 






8 WINNERS 


A 


AD 


S~50 






10 WINNERS 


A A E 


S 2 






50 WINNERS 



164 



GET TICKET DISPLAY 



TICKETS LEFT: 2456 



47 



EP0 907 136 B1 



FIG.16 



XRE0ITS'O3 



AAA 


$200 
4 WINNERS 


A A B 


SI50 
6 WINNERS 


A AC 


SlOO 
8 WINNERS 


"a" AD 


$~50"~' 
lOWINNERS 


A A E 


S 2 
50 WINNERS 




164 



FIG.17 



/Credits '803 



AAA 


S200 
4 WINNERS 


AA B 


SI50 
6 WINNERS 


A A C 

i 


SlOO 
8 WINNERS 


'} A A 0 

1 


S 50 
lOWINNERS 


1 A A E 


$ 2 

50 WINNERS 



TICKETS LEFT' 2455 



170 



• .iiXXXXXXXXXXXXXX 

A. B c xxxxxxxxmxxxx 

ixxxxio^cxxxxxxxx 

lI"Zl"ri"')a)Oodboaxxxxxx''70 ' 

BAA IXXXXXXXXXXXXXXXl-' 
XXXXXXXXXXXXXXXl 



XXXXXXXXXXXXXXX 

AAA IX WINNER $200X1170 

■ XXXXXXXXXXXXXXX KJ 



■I 



- XXXXXXXXXXXXXCC 1170 ; 

C B B I XXXXXXXXXXXXXXX / 

- XXXXXXXXXXXXXXX) ' 



YOU 



164 



WIN 



$200 



Mil 



48 



EP 0 907 136 B1 



FIG. 18 



CMDRSRPT6 



COMMANDS READ- — 
RESPONSES WRITTEN— 



COMMANDS WRITTEN 
RESPONSES READ 



RECORD FOR EACH SLAVE 



AUDIT.PTG ^^82 



INFO WRITTEN ON T 
COMMAND * 



INFO READ TO GENERATE 
AUDIT REPORT 



RECORD FOR EACH SLAVE 




SLAVE 



SYSMSG.PTG 



184 




( MASTER 



MESSAGES READ 
WHEN NEEDED-*- 



■MESSAGES WRITTEN 
WHEN CHANGED 



RECORD FOR EACH MESSAGE 



GAMHDRxx.PTG 



FILES READ TO 
CONFIGURE SLAVE— i 




FILES WRITTEN WHEN 
GAME ACTIVATED 



49 



EP 0 907 136 B1 



F1G.19 



FFFF 



0000 



GAME MAP 
(3 RECORDS) 



GAME CONFIGURATION 
(3 RECORDS) 



NETWORK STATE 



VALIDATION NUMBERS 
(50 RECORDS) 



VALIDATION STATE 



TIME AND DATE 



USERS 
(10 RECORDS) 



MASTER OPTIONS 



SLAVE STATE 
(20 RECORDS) 



COMMAND QUEUES 



190 



192 



194 



196 



198 



202 



200 



204 



206 



208 



50 



